Save point backup performs poorly when resources are over-utilized and underperforms when resources are not sufficiently used. A save point refers to a set of data objects that are backed up and later restored together, such as, for example, a storage volume of a file system or a directory of files. Poor performance typically manifests in volatile environments where multiple save point backups unpredictably compete for some bottlenecked resource along the path from source disk to destination backup devices. Manual configuration and performance history analysis have limited value in controlling future degradation of performance or optimizing it when workloads, scheduling and resulting conflicts are unpredictable. Poor performance can persist throughout backup duration, thereby greatly extending the backup windows of impacted save points. In some cases, backups might even crash. Traditional backup does not dynamically handle either under- or over-utilized resources. Other bulk data transfer applications are similar.
Typical over-utilized, i.e. bottlenecked, resources include client data disks but can also be client memory and central processing unit or CPU, the same for the backup server, backup destination devices, input/output or TO buses and the network. A common specific cause of poor performance is too many data streams from multiple different save point backups stressing the same source mechanical disk(s). This results in wasted disk movement overhead. A single save point backup can also experience poor performance by itself when it uses too many data streams or encounters fragmented disk data during various stages of backup. On the other hand, save point backup can under-utilize these same resources, especially source disks, causing subpar performance.
To achieve optimal throughput, a backup administrator typically needs to experiment and statically (re)configure the number of allocated streams for each save point. This is time consuming, error prone and needs periodic maintenance. This is generally not feasible. The static configuration does not automatically adjust runtime backup streaming to optimize throughput in dynamic environments where a save point's data workload or general resource contention might unexpectedly change during and/or between backup sessions. These environments can manifest often and without warning, especially when users initiate their own backups at any time with ad-hoc workloads sharing the same backup resources.
The static configuration of a save point cannot handle the full resource conflict path from the client source disks to the backup server devices and other workloads. For instance, a non-APC backup administrator might assess that three allocated streams perform better than four for a given save point based on pre-backup or actual backup standalone tests involving just that save point at some unrealistic time of day. However, this approach does not consider other competing save point backups and miscellaneous non-backup workloads that might later conflict with the save point during actual backup time.